7.03. Защита данных
Защита данных
Мы изучили особенности защиты кода. Но как поступают с данными? Для данных нет Git – в гите только код, а данные представляют собой порой огромный объем информации. Но риски бывают те же – удаление, повреждение, изменение, засорение.
Для защиты данных используется резервное копирование (backup, бэкап), это защищает от пропажи данных при сбоях, атаках или ошибках.
Бэкапы баз данных осуществляются по следующим методам:
| Метод | Описание |
|---|---|
| Полный бэкап | Копируется вся база данных (дамп) |
| Инкрементный | Копируются только изменения с момента последнего бэкапа |
| Транзакционные логи | Записываются все изменения |
| Снимки (snapshots) | Полный снимок диска |
Транзакционные логи – журналы всех изменений в БД, которые позволяют восстанавливать данные до момента сбоя, синхронизировать реплики и анализировать историю операций. То есть, при любом изменении в БД, СУБД автоматически записывает сначала операцию в лог, только затем применяет изменения к данным. Примеры:
| СУБД | Лог | Применение |
|---|---|---|
| PostgreSQL | WAL (Write-Ahead Log) | Восстановление, репликация, PITR |
| MySQL | Binlog (Binary Log) | Репликация, восстановление, аудит |
| SQL Server | Transaction Log | PITR, зеркалирование |
| MongoDB | Oplog (Operations Log) | Репликация в шардированных кластерах |
Обычно при резервном копировании БД пишут скрипт, который потом запускают по необходимости. Например, в PostgreSQL пишут pg_dump для полного бэкапа. Для автоматизации можно использовать планировщики задач (допустим, встроенный планировщик задач в Windows), которые будут по расписанию запускать этот исполняемый файл, в котором указана команда для бэкапа.
Бэкапы файлов и программ (документов, конфигураций):
| Метод | Описание |
|---|---|
| Полный бэкап | Копируется вся папка / все файлы |
| Инкрементный | Только новые или изменённые файлы |
| Дифференциальный | Все изменения с момента последнего полного бэкапа |
Для резервного копирования файлов можно использовать инструменты:
- rsync – синхронизация файлов;
- borg / restic – инкрементные бэкапы с шифрованием;
- tar + gzip – упаковка в архив.
Таким образом, для автоматизации бэкапов используется алгоритм:
- Планировщик (cron, system-timer) запускает скрипт;
- Скрипт создаёт бэкап (дамп БД, копия файлов);
- Проверка (если бэкап битый – отправляется предупреждение);
- Ротация (старые бэкапы могут удаляться по правилам).
Но если с порядком всё понятно, то где хранить эти бэкапы?
Как можно заметить, файлы, в отличие от кода, требуют заметно больше ресурсов – места в хранилище. Допустим, если каталог файлов вложений весит 1 ТБ, и делать каждый день полный бэкап, то за месяц улетит уже 30 ТБ места! К тому же, если хранить на том же диске, то при повреждении диска или сервера, смысла от бэкапов не будет – они повредились вместе с оригиналом, поэтому важно определить, где хранить:
- на другом диске того же сервера;
- на другом сервере;
- на специально выделенном сервере-хранилище бэкапов;
- в облаке (допустим AWS S3, Wasabi);
- локально (если серверу конец – конец и данным).
Как восстанавливать данные из бэкапов?
БД восстанавливается средствами СУБД. Главное иметь выгруженный дамп, а дальше уже встроенными инструментами выполнить restore (восстановление).
Файлы же восстанавливаются обычным копированием/распаковкой.
Важно: рекомендуется также ограничить права доступа к бэкапа, чтобы они были неизменяемыми.
Таким образом, защита данных в первую очередь включает в себя:
- RAID - система защиты от отказа дисков.
- Бэкапы - ежедневные/почасовые резервные копии.
- DRP (Disaster Recovery Plan) - полный план восстановления после катастрофы.
- Репликация БД - горячий резерв.
- Балансировка нагрузки позволит распределить трафик между серверами.
- Кластеризация - это высокая доступность через несколько нодов (позже ещё об этом поговорим.